A part editor may store multiple representations of its contents as different values in the content property. Each value must be a full representation that is independent of the other values. This means that if a part changes the content of a single value, eventually it has to make the same change to all other values to keep all of them synchronized. If there is a value written previously by another part editor which is not understood by this part editor, then it is not possible to update that value and that is why such values should be removed. All these changes may be very time consuming. That is why they are done only when a part is externalized.
When a part is being externalized, the data may already be in the storage unit and the various values may be fully synchronized so that no further writing is required. That is why the programmer’s guide suggests that a dirty flag be kept so that there would be no unnecessary writing. This is not an optional optimization. If a part editor does not keep a dirty flag and always does a full externalization, there will be anomalies. Suppose a part editor has written out various values on the storage unit, and then the user switches the part editor. Later the user decides to switch back to the original part editor without making any change using the new part editor. He would expect to see all the values he has before he makes the switch. However the new editor may not support some of the original value types. If the new editor does not use a dirty flag then it is going to remove some perfectly valid values that it does not understand. So the user has unexpectedly lost some of the representations of his data. Another problem is that the user does not expect using the part info dialog to take a peek and then cancel would change his document. Externalization without looking at a dirty flag would modify the document. So it is very important to use a dirty flag to avoid unnecessary externalization.
We agree that a part editor should not delete a value that it does not support if nothing has been changed, but it should delete such values if the content has been changed. Now let us look at the case of dropping a file into an embedding container. In this case you will be getting a value of the file specification information which you can then use to open and read the file. You can then write the new data value. It would be tempting to immediately remove the file specification value. However we should remember the principle that a value should not be removed unless it becomes obsolete. So this is not yet time to remove the file specification. You should wait until the part content has been changed. Then if the user does not like the editor binding, he can switch editor and the new part editor has a chance to read the file again as long as he has not change the content of the part.
